Communication over data networks has become commonplace. Examples of such communications include the use of packet-based digital data to communicate audio and video data in real-time over a data network. Voice and video data sharing, for example, can occur in real time over a data network between two or more users during a streaming videoconference or other virtual meeting.
Required bandwidth to transport the data can be considerable. Taking video conferencing as one example application, multiple participants may be streaming voice, video, and application data with each of the other participants in real time. Each participant may receive all data streams from all other participants. Each participant may be connected to the conference by a network connection that has a different bandwidth capacity from all other connections. Further, other data traffic is often being carried over the network connections that may be unrelated to the videoconference. In some circumstances, the bandwidth capacity on a particular network connection may be saturated or exceeded, and data loss may occur in the conference or other traffic streams.
Solutions have been proposed to avoid this undesirable result. For example, one proposed solution to this problem is to test the network connection(s) prior to an event such as a videoconference to determine available bandwidth, and to predict the required amount of bandwidth for the event. Assuming sufficient capacity exists, the required capacity is then pre-allocated on the network, and each application is configured to transmit no more than the allocated amount.
Success using this method, however, has been limited at best. One significant limitation of this method is that the predicted bandwidth load and the measured bandwidth capacity tend to be static and reflect only one point in time. The actual bandwidth consumed and available, on the other hand, is typically dynamic (varies with time). This is particularly true when communicating over shared network connections where other traffic exists. Also, predicting bandwidth load and measuring network capacity requires pre-event efforts and knowledge that add to the complexity and inaccuracy of this method. Accuracy of the prediction is dependent on a variety of difficult to predict factors. Further, on a shared data network connection (as opposed to dedicated connections) a fixed allocation of bandwidth can require unreasonable overhead in network administration as well as wasted bandwidth.
Another proposed solution has been to make use of real time data communication protocol tools to adjust transmission rates. One protocol used for communicating real time data is Real Time Protocol (“RTP”) and its real time control protocol (“RTCP”). Another proposed solution is to use RTP's control protocol (RTCP) to adjust the transmission rate based feedback from the receiver. One problem using this method is determining when and what value to set the rate. A common technique is to estimate the rate at which TCP-based applications on the same network would use, and use an equal amount of bandwidth. However, this method allows the applications to exceed network capacity, which results in packet loss. This is undesirable since some UDP-based applications (e.g., real-time audio) tolerate loss very poorly.
Known methods have also proven inadequate in using the obtained feedback to accurately predict network congestion. These methods also rely on feedback data obtained using RTCP ports and assume that this data is consistent with the RTP ports. This assumption often fails. This proposed method can also be inadequate in applications such as multi-point videoconferences since decisions are made only at the origination point. This often fails to accurately account for or respond to environments where multiple paths between a sender and multiple receivers exist.
Also, previous proposed solutions to bandwidth control have been almost exclusively designed for point-to-point connections (e.g., unicast). These solutions become less successful and/or impractical in multi-point environments (e.g., multicast, multi-unicast). For example, known methods have proven inadequate in videoconference environments where each participant is receiving multiple data streams from multiple sources.